Methods, devices, and computer readable medium for processing alternative media presentation description

ABSTRACT

This disclosure generally relates to media streaming technologies and more specifically to methods and apparatuses for processing an alternative media presentation description (MPD) with a main MPD from a content server. The method comprises receiving a manifest for the alternative MPD from the content server by a dynamic adaptive streaming over HTTP (DASH) media streaming device; parsing the manifest to extract a set of parameters for the alternative MPD, the set of parameters comprising at least one of a value for a DASH event stream, a presentation time, or a duration; switching from a main media presentation to an alternative media presentation based on the presentation time; and in response to ending the alternative media presentation, playing back the main media presentation at a return point according to the value for the DASH event stream.

INCORPORATION BY REFERENCE

This application is based on and claims the benefit of priority to U.S.Provisional Application No. 63/332,590 filed on Apr. 19, 2022, which isherein incorporated by reference in its entirety.

TECHNICAL FIELD

This disclosure generally relates to media streaming technologies andmore specifically to methods and apparatuses for processing alternativemedia presentation description (MPD) in adaptive streaming.

BACKGROUND

This background description provided herein is for the purpose ofgenerally presenting the context of the disclosure. Work of thepresently named inventor(s), to the extent the work is described in thisbackground section, as well as aspects of the description that may nototherwise qualify as prior art at the effective time of filing of thisapplication, are neither expressly nor impliedly admitted as prior artagainst the present disclosure.

Moving picture expert group (MPEG) dynamic adaptive streaming overhypertext transfer protocol (DASH) provides a standard for streamingmultimedia content over IP networks. In the DASH standard, a mediapresentation description (MPD) is used to provide information for a DASHclient to adaptively stream media content by downloading media segmentsfrom a DASH server. The DASH standard allows the streaming of multi-ratecontent. One aspect of the DASH standard includes carriage of MPD eventsand inband events, and a client processing model for these handlingthese events.

Common Media Application Format (CMAF) is a standard for packaging anddelivering various forms of Hypertext transfer protocol (HTTP) basedmedia. This standard simplifies the delivery of media to playbackdevices by working with, for example, the HTTP Live Streaming (HLS), andDASH protocols to package data under a uniform transport container file.It also employs chunked encoding and chunked transfer encoding to lowerlatency.

MPEG DASH may provide some means for streaming multimedia content overIP networks with alternative MPD events for signaling the mediapresentation between two timelines. There are various issues/problemswith how to process alternative MPD events.

The present disclosure describes various embodiments for processingalternative MPD events, addressing at least one of the issues/problems,advancing the technical field of media streaming.

SUMMARY

This disclosure generally relates to media streaming technologies andmore specifically to methods and apparatuses for processing alternativeMPD events in dynamic adaptive streaming. The alternative MPD events maybe sent by a media content server to a media streaming client and thenare processed by a media streaming client.

According to one aspect, an embodiment of the present disclosureprovides a method by a media streaming device for processing analternative media presentation description (MPD) with a main MPD from acontent server. The method comprises receiving a manifest for thealternative MPD from the content server by the media streaming device;parsing the manifest to extract a set of parameters for the alternativeMPD, the set of parameters comprising at least one of a value for anevent stream, a presentation time, or a duration, wherein thepresentation time indicates an offset in which an alternative mediapresentation starts in a timeline of a main media presentation, and theduration indicates a period in which the alternative media presentationis active; switching from a main media presentation to an alternativemedia presentation based on the presentation time; and in response toending the alternative media presentation, playing back the main mediapresentation at a return point according to the value for the eventstream. The media streaming device comprises a dynamic adaptivestreaming over HTTP (DASH) media streaming device; and the event streamcomprises a DASH event stream.

According to another aspect, an embodiment of the present disclosureprovides a method by a media streaming content server for configuring analternative media presentation description (MPD) with a main MPD andsending the alternative MPD to a media streaming device. The configuredMPD is configured to cause the media streaming device to carry out anyone of the method implementations described in the present disclosure.The media streaming device comprises a dynamic adaptive streaming overHTTP (DASH) media streaming device.

Aspects of the disclosure also provide a media streaming device orapparatus including a circuitry configured to carry out any one of themethod implementations above.

Aspects of the disclosure also provide non-transitory computer-readablemediums storing instructions which when executed by a media streamingdevice are configure to cause the media streaming device to perform anyone of the method implementations above.

The above and other aspects and their implementations are described ingreater detail in the drawings, the descriptions, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features, the nature, and various advantages of the disclosedsubject matter will be more apparent from the following detaileddescription and the accompanying drawings in which:

FIG. 1 illustrates a system according to an embodiment of the presentdisclosure.

FIG. 2 illustrates a Dynamic Adaptive Streaming over HTTP (DASH) systemaccording to an embodiment of the present disclosure.

FIG. 3A illustrates a DASH client architecture according to anembodiment of the present disclosure.

FIG. 3B illustrates another DASH client architecture according to anembodiment of the present disclosure.

FIG. 4 shows a flow diagram of an exemplary embodiment in the presentdisclosure.

FIG. 5 shows a schematic illustration of a computer system in accordancewith example embodiments of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

The invention will now be described in detail hereinafter with referenceto the accompanied drawings, which form a part of the present invention,and which show, by way of illustration, specific examples ofembodiments. Please note that the invention may, however, be embodied ina variety of different forms and, therefore, the covered or claimedsubject matter is intended to be construed as not being limited to anyof the embodiments to be set forth below. Please also note that theinvention may be embodied as methods, devices, components, or systems.Accordingly, embodiments of the invention may, for example, take theform of hardware, software, firmware or any combination thereof.

Throughout the specification and claims, terms may have nuanced meaningssuggested or implied in context beyond an explicitly stated meaning. Thephrase “in one embodiment” or “in some embodiments” as used herein doesnot necessarily refer to the same embodiment and the phrase “in anotherembodiment” or “in other embodiments” as used herein does notnecessarily refer to a different embodiment. Likewise, the phrase “inone implementation” or “in some implementations” as used herein does notnecessarily refer to the same implementation and the phrase “in anotherimplementation” or “in other implementations” as used herein does notnecessarily refer to a different implementation. It is intended, forexample, that claimed subject matter includes combinations of exemplaryembodiments/implementations in whole or in part.

In general, terminology may be understood at least in part from usage incontext. For example, terms, such as “and”, “or”, or “and/or,” as usedherein may include a variety of meanings that may depend at least inpart upon the context in which such terms are used. Typically, “or” ifused to associate a list, such as A, B or C, is intended to mean A, B,and C, here used in the inclusive sense, as well as A, B or C, here usedin the exclusive sense. In addition, the term “one or more” or “at leastone” as used herein, depending at least in part upon context, may beused to describe any feature, structure, or characteristic in a singularsense or may be used to describe combinations of features, structures orcharacteristics in a plural sense. Similarly, terms, such as “a”, “an”,or “the”, again, may be understood to convey a singular usage or toconvey a plural usage, depending at least in part upon context. Inaddition, the term “based on” or “determined by” may be understood asnot necessarily intended to convey an exclusive set of factors and may,instead, allow for existence of additional factors not necessarilyexpressly described, again, depending at least in part on context.

Streaming Over Hypertext Transfer Protocol (HTTP)

FIG. 1 illustrates an example content distribution system 100, in whicha remote information processing apparatus 120 is configured to requestcontents from one or more centralized or distributed content servers 110over a communication network 130. In particular, the informationprocessing apparatus 120 may include dedicated hardware components,software components running on general purpose hardware, or thecombination thereof, which functions as a content consuming application.The content consuming application may generate one or more requestsspecifying the contents being requested and the characteristics of therequested contents. Each request may be constructed based on a stack ofnetwork protocols, and communicated to the content server 110 over thecommunication network 130. In response, the content server may generatea bitstream according to the request, package the bitstream using thestack of network protocols and communicate the bitstream packages to thecontent consuming application.

In some example implementations, the content may be requested at once.In other words, an entirety of a media content may be requested by thecontent consuming application, received, and stored locally. The locallystored content may be processed and consumed as needed (e.g., extracted,decoded, and played back) by, for example a media player, either beingpart of or separate from the content consuming application. Such aprocess may be referred to as downloading.

In some other implementations, the content may be streamed as it isbeing consumed rather than being downloaded for later consumption. Insuch implementations, the entirety of the requested content may not needto be stored in the content consuming application. Rather, only alimited amount of content is continuously received from the contentserver 110 on a rolling basis and managed by an in-and-out local bufferfor content processing and playback. Such implementations may bereferred to as streaming. While some media playback functions, such asrewinding, fast-forwarding, and seeking may involve complex mediabitstream control and buffering, media streaming is usually moreversatile and more suitable for distribution of contents containingtimed sequences of media that are not repeated consumed.

In the disclosure below, the terms “content” and “media” may be usedinterchangeably. A requested content may include various informationitems needed for its consumption, including but not limited to thecontent itself and various metadata. The content itself, may furtherinclude various media components, such as different tracks, includingbut not limited to video components/tracks, audio components/tracks,subtitles, and the like. Metadata for describing the media content orproviding additional processing information may be treated as one ormore separate tracks. Such content with its metadata may be generated bythe content server 120 as a bitstream that can be parsed and decodedaccording to a set of protocols or rules known to the content consumingapplication. The term “content server” in its singular form is used torepresent a single server or a plurality of servers arranged in acentral location or distributed over various geographical locations.Such content servers may be implemented as dedicated computing machines,or alternatively, may be constructed as virtual machines, and/or asvirtually hosed in a cloud computing environment. Further in thedisclosure below, the terms “information processing apparatus”(referring to 120 of FIG. 1 ) and “content consuming application” may beused interchangeably. These terms may also be alternatively referred toas “client,” “client devices/apparatus,” “playbackdevices/apparatus/client,” and the like. While only a single informationprocessing apparatus 120 is shown in FIG. 1 , there can be a pluralityof independent information processing apparatus. In other words, a setof content servers 110 may be configured to simultaneously andindependently provide streaming service to a plurality of contentconsuming applications.

In some example implementations, contents generated for distribution bythe content server 110 may be segmented to facilitate their streaming.For example, timed sequences of media contents such as movies, may bechopped into time segments, each containing a number of media frames.Each media segment may be self-contained such that its processingincluding, for example, parsing, decoding, and playback, does notrequire information for other media segments. The media contents may bepre-segmented. Accordingly, the media contents may be stored and managedby the content server 120 segment by segment. Alternatively, mediasegments may be generated in real-time from contiguously stored mediacontents as they are being requested during streaming processes. In somefurther implementations, the segmentation of the media may behierarchical, containing multiple levels of segmentation.

In some particular implementations for streaming, decision as to whichmedia segments or which portions of the media segments to request fromthe content server 110 may be determined by a content consumingapplication in real time as controlled by user play-back instructionsthrough a user application interface. In such a manner, the contentserver may be configured to respond to the requests and generate orretrieve segments or portions of segments of the content with theirmetadata according to the requests, and deliver the segments or portionsof the segments to the requesting content consuming application over thenetwork 130.

In some example implementations, a same media track of a media contentmay be prepared as different versions. For example, the same movie trackmay be prepared in different resolutions and/or frame rate. For anotherexample, the same movie track may be prepared in different bitrates. Foranother example, the same audio movie may be prepared with differentsound quality and/or different number of sound channels (e.g., 5-channelsound, or 7-channel sound). Accordingly, the content consumingapplication may determine which version of the media tracks to streamand include such selection in its requests for media content. Suchdecision by the content consuming application, may be made based on oneor more of a number of example factors, including but not limited to theplayback capabilities of the information processing apparatus 120 (e.g.,display resolution, decoding speed, processing power, buffer size, andthe like), the network bandwidth and throughput, and the like. As such,the streaming session may be adapted among different media consumingapplications according to their device capabilities. A streamingarchitecture so configured may be referred to as adaptive streaming. Thestreaming process may further be adaptive within each media consumingapplication in that different versions of the media tracks may beselected and requested at different times during a streaming session,according to, for example, a real-time network condition (for example,bandwidth and throughput, and bitrate supported by the networkbandwidth). A streaming architecture so configured may be furtherreferred to as dynamic adaptive streaming. In particular, a streamingarchitecture configured to adapt to bitrates of the media content may bereferred to as dynamic adaptive bitrate streaming.

In some example implementations, a request for a particular version ofsegments or portions of segments of media content by the contentconsuming application in dynamic adaptive streaming may be constructedbased on a media manifest according to the progression of the streamingsession. The term “manifest” may be used to represent any collection ofinformation items that describe the media content, including thesegmentation, versions, network locations, and any other informationthat may be needed for any content consuming application to determinehow and what to request at different times during a streaming session. Amanifest may be generally referred to as a “media presentationdescription” (MPD).

Such a manifest may be prepared on the content server side at the timewhen a particular media content is created or generated. Such a manifestmay be requested by the content consuming application and received fromthe content server at the beginning of a streaming session. The contentconsuming application may further request any update of the manifestduring the streaming session. Such manifest may be used by the contentconsuming device as a blueprint for constructing the subsequent requestsof particular version of segments or portions of segments of the mediacontent during the streaming session.

In some example implementations, the media server may be configured tofunction similarly to a web server from the stand points of externalapplications. As such, a request for a media manifest and/or for mediasegments or portions of media segments by a content consumingapplication may be made based on, for example, the hypertext transferprotocol (HTTP). As such, a request may be constructed as a URL and therequested content may be delivered as a response to the HTTP requestfrom the content server.

Details for the manners in which the manifests are specified, thecontents are segmented, organized, and versioned, and the HTTP requestsare constructed may depend on specific adaptive streaming protocol, suchas Dynamic Adaptive Streaming over HTTP (DASH), HTTP Live Streaming(HLS), Smooth Streaming Transport Protocol (SSTP), and the like. Thevarious additional example implementations below may be described in thecontext of DASH. However, the underlying principles are applicable toany type of adaptive streaming over HTTP. Further, the underlyingprinciples are applicable to media content request mechanism based onnetwork protocols other than HTTP.

Dynamic Adaptive Streaming Over HTTP (DASH)

One example protocol for implementing adaptive media streaming includesDynamic Adaptive Streaming over Hypertext transfer protocol (DASH). Asdescribed above, DASH represents one of the adaptive bitrate streamingimplementations that enables streaming of media content using contentdelivery networks (CDNs) based on hypertext transfer protocol (HTTP)infrastructures, including content servers configured as web serverswith various proxies and caches, and the like. Such content servers maybe referred to as DASH servers. The content consuming applicationsdescribed above may accordingly be referred to as DASH clients.

DASH supports live streaming from a DASH server to a DASH client, andallows the DASH client to control a streaming session, so that the DASHserver does not need to cope with an additional load of streamadaptation management in large scale deployments. As described above,DASH also allows the DASH client a choice of streaming from various DASHservers, thereby achieving further load-balancing of the network for thebenefit of the DASH client. DASH further provides dynamic switchingbetween different media versions of the media tracks, for example, byvarying bitrates to adapt to network conditions and processingcapability of a DASH client.

In DASH, the media manifest described above may be particularly referredto as an MPD (even though the term MPD may be generally used to refer tomanifest of any type in adaptive streaming systems other than the onesbased on DASH). For example, an MPD in DASH may be constructed as a filethat is downloadable in full or in part by a DASH client and thatprovides information items used by the DASH client to stream the mediacontent by selectively and adaptively requesting streaming mediasegments from the DASH server.

An MPD may be constructed in various formats. For example, an MPD may beconstructed in the form of an Extensible Markup Language (XML) documentor file. The MPD file may be requested and delivered to the DASH client.The MPD file may be requested by HTTP via, for example, an HTTP GETrequest. The MPD file may be delivered entirely at the beginning of astreaming session. Alternatively, the MPD file can be fragmented anddelivered in parts. As such, parts of the MPD file may be requested anddelivered prior to the start of the streaming and other parts of the MPDfile may be requested and delivered later to reduce session start-updelay (such that the streaming can begin with the earlier media segmentswithout having to wait for information items pertaining to latersegments of the media). The MPD file can also be updated during thestreaming session (e.g., with the segment information that is needed butis not yet retrieved).

In some example implementations, the MPD file describes the segmentationof the media content, the organization of the segments, and availableversions of the segments. The MPD may support expression of contentaccessibility features, ratings, camera views, metadata, and the like.DASH may also support delivery of multi-view and scalable coded content.

In some example implementations, an MPD file may contain a sequence ofdescriptions for one or more periods along a media consumption timeline(e.g., play time of a video content). Each of the one or more periodsmay be defined by, for example, a “period” information element tag inthe MPD file. The media content may be indicated by the MPD file asorganized in a plurality of continuous periods in time. The MPD file mayidentify a start time for each of the periods in the playback timeline.The start time may be defined as an absolute start time from a beginningof the media content or as a relative offset from other reference pointin the playback timeline.

In some example implementations, for each media period, the MPD file mayfurther specify one or more adaptations sets. Different adaptation setsmay be specified to capture different combinations (or subset) of one ormore of the media components. For example, video and audio can bedifferent adaptation sets. Different versions of audios (stereo audio ormulti-channel audio) may be different adaptation set. Audio of differentlanguage may be different adaptation sets. In one particular example,the MPD file may specify that each period contains one video adaptationset, multiple audio adaptation sets, one for each of the supportedlanguages. Adaptation sets may also contain subtitles or arbitrarymetadata.

In some example implementations, adaptation sets of a particular periodmay be assigned to a group indicated by a group attribute in the MPDfile. Adaptation sets in the same group are generally consideredalternatives to each other. For example, each adaptation set of videodata for a particular period can be assigned to the same group, suchthat any adaptation set can be selected for video data of the multimediacontent for the corresponding period. The media content within oneperiod can be from either one adaptation set, or a combination ofadaptation sets, with each group contributing at most one adaptationset.

In some example implementations, each adaptation set may be specified bythe MPD file as containing one or more representations for the samemedia component for the corresponding period. A representation, forexample, can be one of a number of alternative encoded versions of audioor video data. The representations can differ by encoding types, e.g.,by bitrate, resolution, and/or codec for video data, and bitrate, and/orcodec for audio data. The term representation can be used to refer to asection of encoded media data corresponding to a particular period ofthe multimedia content and encoded in a particular way to achieve acertain range of average bitrate. In some examples implementations, foreach representation in an adaptation set, the MPD file may specifyattributes of the representation including but not limited tovideo/audio type, video/audio codecs, video frame width in pixels, videoframe height in pixels, video/audio frame rate, and bandwidth(representing average encoded bitrate).

Each representation of an adaptation set may also include one or moremedia components depending the combination of media components includedin the adaptation set. Each media component in a representation maycorrespond to an encoded version of one individual media type, such asaudio, video, or timed text (e.g., for closed captioning). Mediacomponents can be time-continuous across boundaries of consecutive mediasegments within one representation.

In some example implementations, a representation may include one ormore segments. Each representation can include an initializationsegment, or each segment of a representation can be self-initializing.When present, the initialization segment can contain initializationinformation for accessing the representation. In some cases, theinitialization segment does not contain media data. Segments thatcontain media data may represent the time-segmented contents. Segmentsbetween different representations may be aligned in time. For each mediasegment, the MPD file may include a unique identifier. Such anidentifier, when combined with a basis URL, a base URN, or base uniformresource identifier (URI), may form a unique URL, URN or URI thatrepresents a network location of the media segment, which may beincluded in an HTTP request for this media segment and be used by thecontent server to locate the requested segment for delivery.

For example, a URL for requesting a media segment can be defined as an<absolute-URI>, with a fixed scheme of “http” or “https”, possiblyfurther supplemented by a byte range if a range attribute is providedtogether with the URL. The byte range can be expressed to identifying acontiguous range of bytes in the segment.

In some further example implementations, sub-representations may bespecified and described in the MPD file as being embedded (or contained)in regular representations using, for example, a Sub-Representationelement/indicator. The sub-representation element may be used todescribe properties of one or several media content components that areembedded in the representation. For example, the sub-representationelement may be used to describe properties of an embedded audiocomponent (e.g., codec, sampling rate, etc.), an embedded sub-title(e.g., codec), or the sub-representation element may be used to describesome embedded lower quality video layer (e.g., some lower frame rate,etc.). Sub-representation and representation elements can share somecommon attributes and elements.

In some example implementations, the DASH client may be configured toaccess, download, and request an entirety or a portion of the MPD filefrom the DASH server. That is, the DASH client may retrieve the MPD filefor use in initiating a live streaming session. Based on the MPD file,and selection of a representation, the DASH client can make severalfurther decisions, including determining what is the latest segment thatis available on the server, determining the segment availability starttime of the next segment and possibly future segments, determining whento start playback of the segment, and determining when toget/fetch/request a new MPD file.

In some example implementations, the MPD may further include informationabout DASH events in order to signal aperiodic information to DASHclients or DASH applications. Events may be timed, starting at aspecific media presentation time with a duration. Additionally oralternatively, the event information may include control messages for amedia player that are associated with specific times during playback ofthe media presentation, such as advertisement insertion cues. Media thatmay be inserted during streaming may be provided from separate servers,such as an advertisement server. In addition to signaling the events byMPD separately from the media representations, events may also bemultiplexed in-band in a selected media representation in one or severalselected adaptation sets only, or in all representations.

An exemplary DASH system 200 is illustrated in FIG. 2 . The DASH system200 may include one or more centralized or distributed content servers210 and an information processing apparatus 230 which are connected by anetwork 250. The DASH system (200) may also include one or moresupplemental content servers such as one or more advertisement server220.

The content server 210 may provide primary content (e.g., a mainprogram) and an MPD for the content, to the information processingapparatus 230. The manifest file can be generated by an MPD generator214. The primary content and the manifest file can be provided by a samesever or different servers.

The information processing apparatus 230 may include a DASH client 232that directly communicate with the content server 210. The DASH client232, controlled by a DASH application 234 of the information processingapparatus 230, may request and/or receive the MPD and may request andacquire primary content from an HTTP server 212 of the content server210 based on the MPD. The MPD may be processed by the DASH client 232.Further, the DASH client 232 may acquire advertisement content from theadvertisement server 220, or other content (e.g., interactive content)from one or more supplemental content servers according to DASH events.The main content and the advertisement content can be processed by theDASH client 232 and the DASH application 234 and output for display on adisplay device 236 of the information processing apparatus 230. Thedisplay device 236 may be integrated with, or external to, theinformation processing apparatus 230. Further, the DASH client 232 mayextract other event information from one or more timed metadata tracksand send the extracted event information to the DASH application 234 forfurther processing. The DASH application 234 may be configured, forexample, to display supplemental content based on the event information.

An example for the DASH client 232 is illustrated in FIG. 3A. Theexample DASH client 232 may include a DASH access engine 304, aselection logic 302, and media engines 306 and 308. The DASH accessengine 302, for example, may be configured to communicate with thecontent server for retrieving a portion of or an entirety of the MPD ofthe streaming media, and for requesting and retrieving segment data ofthe dynamically requested streaming media as well as for requestingsupplemental media (advertisement) according to MPD DASH events. Theselection logic 304 may be configured to determine the next one or moresegments to request including selection of adaptation sets andrepresentations. Such decision for example, may be determined by userinstructions as well as by other real time information such as thenetwork bandwidth and throughput. The media engines 306 may beconfigured to process the segment data received by the DASH accessengine 302 according to a format of the media segments (e.g., MPEG) andtiming of the media segments to generate main media output. The mediaengine 308 may be configured to process media content associated withtimed DASH events from the DASH Access Engine 302 to generatesupplemental media output (such as advertisement), which, for example,may be inserted into the main media output.

FIG. 3B illustrates another example DASH/CMAF client architecture forprocessing DASH and/or CMAF events according to an embodiment of thepresent disclosure. The DASH/CMAF client (or DASH/CMAF player) can beconfigured to communicate with an application (390) and process varioustypes of events, including (i) MPD events, (ii) inband events, and (iii)timed metadata events.

A manifest parser (305) parses a manifest (e.g., an MPD). The manifestis provided by the content server (110, 210), for example. The manifestparser (305) extracts event information about MPD events, inband events,and timed metadata events embedded in timed metadata tracks. Theextracted event information can be provided to DASH logic (310) (e.g.,DASH player control, selection, and heuristic logic). The DASH logic(310) can notify an application (390) of event schemes signaled in themanifest based on the event information.

The event information can include event scheme information fordistinguishing between different event streams. The application (390)can use the event scheme information to subscribe to event schemes ofinterest. The application (390) can further indicate a desired dispatchmode for each of the subscribed schemes through one or more subscriptionAPIs. For example, the application (390) can send a subscription requestto the DASH client that identifies one or more event schemes of interestand any desired corresponding dispatch modes.

If the application (390) subscribes to one or more event schemes thatare delivered as part of one or more timed metadata tracks, an inbandevent and ‘moof’ parser (325) can stream the one or more timed metadatatracks to a timed metadata track parser (330). For example, the inbandevent and ‘moof’ parser (325) parses a movie fragment box (“moof”) andsubsequently parses the timed metadata track based on controlinformation from the DASH logic (310).

The timed metadata track parser (330) can extract event messagesembedded in the timed metadata track. The extracted event messages canbe stored in an event buffer (335) (e.g., an event buffer). Asynchronizer/dispatcher module (340) (e.g., event and timed metadatasynchronizer and dispatcher) can dispatch (or send) the subscribedevents to the application (390).

MPD events described in the MPD can be parsed by the manifest parser(305) and stored in the buffer (335). For example, the manifest parser(305) parses each event stream element of the MPD, and parses each eventdescribed in each event stream element. For each event signaled in theMPD, event information such as presentation time and event duration canbe stored in the buffer (335) in association with the event.

The inband event and ‘moof’ parser (325) can parse media segments toextract inband event messages. Any such identified inband events andassociated presentation times and durations can be stored in the buffer(335).

Accordingly, the buffer (335) can store therein MPD events, inbandevents, and/or timed metadata events. The buffer (335) can be aFirst-In-First-Out (FIFO) buffer, for example. The buffer (335) can bemanaged in correspondence with a media buffer (350). For example, aslong as a media segment exists in the media buffer (350), any events ortimed metadata corresponding to that media segment can be stored in thebuffer (335).

A DASH Access Application Programming Interface (API) (315) can managethe fetching and reception of a content stream (or dataflow) includingmedia content and various metadata through an HTTP protocol stack (320).The DASH Access API (315) can separate the received content stream intodifferent dataflows. The dataflow provided to the inband event and moofparser can include media segments, one or more timed metadata tracks,and inband event signaling included in the media segments. In anembodiment, the dataflow provided to the manifest parser 305 can includean MPD.

The DASH Access API (315) can forward the manifest to the manifestparser (305). Beyond describing events, the manifest can also provideinformation on media segments to the DASH logic (310), which cancommunicate with the application (390) and the inband event and moofparser (325). The application (390) can be associated with the mediacontent processed by the DASH client. Control/synchronization signalsexchanged among the application (390), the DASH logic (310), themanifest parser (305), and the DASH Access API (315) can control thefetching of media segments from the HTTP Stack (320) based oninformation regarding media segments provided in the manifest.

The inband event and moof parser (325) can parse a media dataflow intomedia segments including media content, timed metadata in a timedmetadata track, and any signaled inband events in the media segments.The media segments including media content can be parsed by a fileformat parser (345) and stored in the media buffer (350).

The events stored in the buffer (335) can allow thesynchronizer/dispatcher (340) to communicate to the application theavailable events (or events of interest) related to the applicationthrough an event/metadata API. The application can be configured toprocess the available events (e.g., MPD events, inband events, or timedmetadata events) and subscribe to particular events or timed metadata bynotifying the synchronizer/dispatcher (340). Any events stored in thebuffer (335) that are not related to the application, but are insteadrelated to the DASH client itself can be forwarded by thesynchronizer/dispatcher (340) to the DASH logic (310) for furtherprocessing.

In response to the application (390) subscribing to particular events,the synchronizer/dispatcher (340) can communicate to the applicationevent instances (or timed metadata samples) corresponding to eventschemes to which the application has subscribed. The event instances canbe communicated in accordance with a dispatch mode indicated by thesubscription request (e.g., for a specific event scheme) or a defaultdispatch mode. For example, in an on-receive dispatch mode, eventinstances may be sent to the application (390) upon receipt in thebuffer (335). On the other hand, in an on-start dispatch mode, eventinstances may be sent to the application (390) at their associatedpresentation time, for example in synchronization with timing signalsfrom the media decoder (355).

In some implementations, a media segment engine (MSE) (395) may includethe file format parser (345), the media buffer (350), and the mediadecoder (355). The MSE may receive media segments and generate thedecoded media output.

Configuring and Processing Alternative MPD

In some implementations allows the streaming of multi-rate content, andutilizes alternative MPD events for switching media presentationsbetween two timelines: one timeline for a main MPD event for a mainmedia presentation; and another timeline for an alternative MPD eventfor an alternative media presentation. There may be some issues/problemswith how to provide a client post-processing model.

For example, some implementations with DASH design may include one ormore of the following issues/problems: no return point for on-demandcontent; assumption of the switch time being the same as the event starttime; and/or assumption of the advertisement (ad) duration being thesame as the event duration.

Various embodiments describe a processing model for the DASH client toprovide, dispatch, and post-process the alternative MPD events. Someimplementations provide different signaling and improved post-processingmodels that correctly processes the alternative MPD events, for example,efficiently and effectively enabling preroll and/or midrolladvertisements.

Various embodiments may also address one or more of the issues/problemsdescribed in the present disclosure. For example, some embodiments mayimprove the media streaming field by one or more of the following:adding the return point for on-demand content; separating these twoparameters (switch time and event start time) to achieve preroll andmidroll correctly; and/or separating these two parameters (advertisementduration and event duration) to achieve switching to and back from adcorrectly.

Referring to FIG. 3B, a client may request the media segments based onthe described addresses in the manifest. The MSE buffer may include apipeline of the file format parser, the media buffer, and the mediadecoder.

FIG. 4 shows an example flow diagram of one exemplary method 400 by amedia streaming device (e.g., dynamic adaptive streaming over HTTP(DASH) media streaming device) for processing an alternative mediapresentation description (MPD) with a main MPD from a content server.The method 400 may include a portion or all of the following steps: step410, receiving a manifest for the alternative MPD from the contentserver by the DASH media streaming device; step 420, parsing themanifest to extract a set of parameters for the alternative MPD, the setof parameters comprising at least one of a value for an event stream(e.g., a DASH event stream), a presentation time, or a duration, whereinthe presentation time indicates an offset in which an alternative mediapresentation starts in a timeline of a main media presentation, and theduration indicates a period in which the alternative media presentationis active; step 430, switching from a main media presentation to analternative media presentation based on the presentation time; and/orstep 440, in response to ending the alternative media presentation,playing back the main media presentation at a return point according tothe value for the DASH event stream.

In various embodiments, the present disclosure provides methods for amedia streaming content server to configuring an alternative mediapresentation description (MPD) with a main MPD. The media streamingcontent server may send the configured alternative MPD to a mediastreaming device, and may configure the media streaming device to carryout a portion or all of the method 400, or any other implementationsdescribed in the present disclosure.

In some implementations, the presentation time is a different parameterfrom an actual switching time.

In some implementations, the duration is a different parameter from anactual duration of the alternative media presentation.

In some implementations, the value for the event stream comprises afirst value indicating timeshift; and/or the main media presentation isplayed back to a moment that the main media presentation is switched tothe alternative media presentation.

In some implementations, the value for the event stream comprises asecond value indicating replace; and/or in response to a first MPD typeindicating dynamic, the main media presentation is played back to a liveedge of the main media presentation; and/or in response to a second MPDtype indicating static, the main media presentation is played back to amoment that the main media presentation is switched to the alternativemedia presentation plus an actual duration of the alternative mediapresentation.

In some implementations, the alternative MPD is processed and dispatchedaccording to a dynamic adaptive streaming over hypertext transferprotocol (DASH) event processing.

In some implementations, the step of ending the alternative mediapresentation comprises at least one of the following: ending playing thealternative media presentation at an end of the duration; or stoppingplaying the alternative media presentation upon receiving a stopinstruction.

In some implementations, in response to an MPD type indicating dynamic:in response to the value indicating replace, a return point for playingback the main media presentation is a live edge of the main mediapresentation; and/or in response to the value indicating timeshift, thereturn point for playing back the main media presentation is an earliestsegment available at or after an actual switching time.

In some implementations, in response to an MPD type indicating static:in response to the value indicating replace, a return point for playingback the main media presentation is a summation of an actual switchingtime and an actual duration of the alternative media presentation;and/or in response to the value indicating timeshift, the return pointfor playing back the main media presentation is the actual switchingtime.

A parameterization descriptor for media segment requests may be referredto as an MPD data structure. For a non-limiting example, an instantiateddata structure of such a type in an MPD, referred to as “UrlQueryInfo”,may contain various attributes or descriptors that are used to providethe static as well as dynamic parameterization mechanism for mediasegments. In some further example implementations, such a static anddynamic parameterization mechanism may be extended to other types ofHTTP requests in addition to requests for media segments. An examplesyntax for an extension data structure type may be specified and may beused to instantiate an MPD containing a corresponding data structure forsignaling and prescribing parametrization of the various types (orattributes or values).

Table 1 shows a non-limiting example for corrected and/or improvedsemantics for alternative MPD signaling.

TABLE 1 Relevant parameters for alternative MPD event in MPD AttributeValue Event Stream@schemeIdUri/ ″urn:mpeg:dash:event:alternative:2022″InbandEventStream@schemeIdUri EventStream@value/ - ″replace″ to returnto InbandEventStream@value i. the Media Presentation live edge in thecase MPD@type=′dynamic′, or ii. (the time in Media Presentation in whichthe playback is being switched to the alternative Presentation + thealternative Media Presentation duration) in the case MPD@type=′static′ -″timeshift″ to return to the moment in Media Presentation that theplayback is switched to the alternative Media PresentationEvent@presentationTime The offset in which the event for MediaPresentation Insertion becomes active. The anchor for each offsetparameter is defined in 5.10.3.2 accordingly. Event@duration Theduration in which the event for Media Presentation Insertion is active.Event body URL of the MPD representing the alternative MediaPresentation. If this URL does not resolve to a valid MPD, the playbackis continued with the main Media Presentation.

Table 2 shows another non-limiting example for corrected and/or improvedsemantics for alternative MPD signaling.

TABLE 2 Relevant emsg parameters for alternative MPD event AttributeValue scheme_id_uri ″urn:mpeg:dash:event:alternative:2022″ value -″replace″ to return to i. the Media Presentation live edge in the caseMPD@type=′dynamic′, or ii. (the time in Media Presentation in which theplayback is being switched to the alternative Presentation + thealternative Media Presentation duration) in the case MPD@type=′static′ -″timeshift″ to return to the moment in Media Presentation that theplayback is switched to the alternative Media Presentation presentation_The offset in which the event for Media Presentation time_delta/_Insertion becomes active. The anchor for each offset prsentation_timeparameter is defined in 5.10.3.2 accordingly. event_duration Theduration in which the event for Media Presentation Insertion is active.message_data The MPD URL of the alternative Media Presentation. If thisURL does not resolve to a valid MPD, the playback is continued with themain Media Presentation.

Various embodiments includes a client post-processing model foralternative MPD events. In some implementations, the alternative MPDevent is processed and dispatched according to general DASH eventprocessing. In some implementations, the alternative MPD event may bepost-processed after being dispatched. Table 3 shows a non-limitingexample of parameters, on which the post-processing procedure of theevent may rely.

TABLE 3 Event/timed metadata API parameters and datatypes API ParameterMPD event Inband event values scheme_id Event Stream@ scheme_id_uri″urn:mpeg:dash:event:alternative:2022″ schemeIdUri value EventStream@value - ″replace″ to return to value i. the Media Presentation live edgein the case MPD@type=′dynamic′, or ii. (the time in Media Presentationin which the playback is being switched to the alternativePresentation + the alternative Media Presentation duration), in the caseMPD@type=′static′ - ″timeshift″ to return to the moment in MediaPresentation that the playback is switched to the alternative MediaPresentation presentation_ Event@ presentation_ The offset in which theevent starts time presentationTime time in the media presentationtimeline duration Event@duration duration The duration in which theevent is active Message Event body message_data The MPD URL of thealternative Media Presentation.

In the present disclosure, a uniform resource name (URN) such as“urn:mpeg:dash:event:alternative:2022” may be defined and used alongwith optional substrings defined by owner(s) of the URN/URL scheme.

For one non-limiting example for a client's alternative MPD switchingevent post-processing procedure, a method may include one or more thefollowing steps.

For step 1, a media streaming client (or media streaming device, orclient) checks whether an alternative MPD uniform resource locator (URL)in a message is in its previously played list (PPL).

For step 2, when the client determines the alternative MPD URL is in itsPPL, the client may not take any further action; and/or when the clientdetermines the alternative MPD URL is not in its PPL, the client maycontinue one or more of the following steps.

For step 3, the client downloads the alternative MPD.

For step 4, the client determines and performs one of the followingcases.

For step 4-1, when the client determines that a current playback time≥apresentation_time, it immediately goes to next step (step 5). In someimplementations, the current playback time may indicate a current timeof the main media presentation; and/or the presentation_time mayindicate a “target” time to switch to the alternative mediapresentation.

For step 4-2, when the client determines that the current playbacktime<the presentation_time, it continues playback of the main mediapresentation until the current playback time=the presentation_time,which is satisfying step 4-1, and then goes to next step.

For step 5, the client sets a switch_time=current playback time. Then,it switches the playback from the main media presentation to thealternative media presentation as long as the main media presentation isnot ended. When the main media presentation is ended, it stops andclears its switch_time and PLL buffers.

For step 6, the client stores the main MPD URL and the switch_time.

For step 7, the client adds the message to its PPL.

For step 8, the client, at the end of the alternative mediapresentation, downloads the main MPD from the main MPD URL. Thealternative media presentation may be ended because of at least one ofthe following: ending playing the alternative media presentation at anend of the duration (i.e., the alternative media presentation completesits configured duration); or stopping playing the alternative mediapresentation upon receiving a stop instruction (i.e., a user or thecontent server ends playing of the alternative media presentation beforethe alternative media presentation completes its configured duration).

For step 9, the client continues playing back the main mediapresentation based on one of the following steps according to the valueand/or a MPD type:

For step 9-1, in response to MPD @type=‘dynamic’: when thevalue=‘replace’, the playback time position is from the live edge;and/or when the value=‘timeshift’, the playback time position is fromthe earliest segment available at or after the switch_time. In someimplementations, @timeshiftBufferDepth may be set to a value equal to orlarger than the maximum alternative media presentation duration so as toassure that the media segments would be available at the switch_timewhen playback is returned to the main media presentation.

For step 9-2, in response to MPD@type=‘static’: when thevalue=‘replace’, the playback time position is from(switch_time+duration of alternative media presentation); and/or whenthe value=‘timeshift’, the playback time position is from theswitch_time.

In some implementations, a DASH client clears its URL, switch_time, andPPL values starting at the first parsing of the main MPD and continuemaintaining them during the entire playback.

In some implementations, a event presentation_time and a durationindicate the active time interval of a media presentation in which themedia presentation is switched to the alternative media presentation.The exact time of switching (the switch_time) depends on how the playerreaches the active time interval, e.g., by linear playback to its starttime, or by random access to a moment in the middle of it.

Various embodiments may include a method for processing the alternativeMPD events wherein the event start time and event duration aremaintained as different parameters as switching time and alternative adduration. The event start time and duration defines the time intervalthat the switching time may occur while the switching time may changedepending on the player's linear playback of the content or randomaccessing the content in the middle, and the time of switching back isdefined by the alternative ad duration, not the event duration. In theprocessing model, these values are maintained and treated separately,and the signaling of alternative MPD event semantics are definedconsidering the described processing model.

The techniques described above, can be implemented as computer softwareusing computer-readable instructions and physically stored in one ormore computer-readable media. For example, FIG. 5 shows a computersystem (500) suitable for implementing certain embodiments of thedisclosed subject matter.

The computer software can be coded using any suitable machine code orcomputer language, that may be subject to assembly, compilation,linking, or like mechanisms to create code comprising instructions thatcan be executed directly, or through interpretation, micro-codeexecution, and the like, by one or more computer central processingunits (CPUs), Graphics Processing Units (GPUs), and the like.

The instructions can be executed on various types of computers orcomponents thereof, including, for example, personal computers, tabletcomputers, servers, smartphones, gaming devices, internet of thingsdevices, and the like.

The components shown in FIG. 5 for computer system (500) are exemplaryin nature and are not intended to suggest any limitation as to the scopeof use or functionality of the computer software implementingembodiments of the present disclosure. Neither should the configurationof components be interpreted as having any dependency or requirementrelating to any one or combination of components illustrated in theexemplary embodiment of a computer system (500).

Computer system (500) may include certain human interface input devices.Such a human interface input device may be responsive to input by one ormore human users through, for example, tactile input (such as:keystrokes, swipes, data glove movements), audio input (such as: voice,clapping), visual input (such as: gestures), olfactory input (notdepicted). The human interface devices can also be used to capturecertain media not necessarily directly related to conscious input by ahuman, such as audio (such as: speech, music, ambient sound), images(such as: scanned images, photographic images obtain from a still imagecamera), video (such as two-dimensional video, three-dimensional videoincluding stereoscopic video).

Input human interface devices may include one or more of (only one ofeach depicted): keyboard (501), mouse (502), trackpad (503), touchscreen (510), data-glove (not shown), joystick (505), microphone (506),scanner (507), camera (508).

Computer system (500) may also include certain human interface outputdevices. Such human interface output devices may be stimulating thesenses of one or more human users through, for example, tactile output,sound, light, and smell/taste. Such human interface output devices mayinclude tactile output devices (for example tactile feedback by thetouch-screen (510), data-glove (not shown), or joystick (505), but therecan also be tactile feedback devices that do not serve as inputdevices), audio output devices (such as: speakers (509), headphones (notdepicted)), visual output devices (such as screens (510) to include CRTscreens, LCD screens, plasma screens, OLED screens, each with or withouttouch-screen input capability, each with or without tactile feedbackcapability-some of which may be capable to output two dimensional visualoutput or more than three dimensional output through means such asstereographic output; virtual-reality glasses (not depicted),holographic displays and smoke tanks (not depicted)), and printers (notdepicted).

Computer system (500) can also include human accessible storage devicesand their associated media such as optical media including CD/DVD ROM/RW(520) with CD/DVD or the like media (521), thumb-drive (522), removablehard drive or solid state drive (523), legacy magnetic media such astape and floppy disc (not depicted), specialized ROM/ASIC/PLD baseddevices such as security dongles (not depicted), and the like.

Those skilled in the art should also understand that term “computerreadable media” as used in connection with the presently disclosedsubject matter does not encompass transmission media, carrier waves, orother transitory signals.

Computer system (500) can also include an interface (554) to one or morecommunication networks (555). Networks can for example be wireless,wireline, optical. Networks can further be local, wide-area,metropolitan, vehicular and industrial, real-time, delay-tolerant, andso on. Examples of networks include local area networks such asEthernet, wireless LANs, cellular networks to include GSM, 3G, 4G, 5G,LTE and the like, TV wireline or wireless wide area digital networks toinclude cable TV, satellite TV, and terrestrial broadcast TV, vehicularand industrial to include CAN bus, and so forth. Certain networkscommonly require external network interface adapters that attached tocertain general-purpose data ports or peripheral buses (549) (such as,for example USB ports of the computer system (500)); others are commonlyintegrated into the core of the computer system (500) by attachment to asystem bus as described below (for example Ethernet interface into a PCcomputer system or cellular network interface into a smartphone computersystem). Using any of these networks, computer system (500) cancommunicate with other entities. Such communication can beuni-directional, receive only (for example, broadcast TV),uni-directional send-only (for example CANbus to certain CANbusdevices), or bi-directional, for example to other computer systems usinglocal or wide area digital networks. Certain protocols and protocolstacks can be used on each of those networks and network interfaces asdescribed above.

Aforementioned human interface devices, human-accessible storagedevices, and network interfaces can be attached to a core (540) of thecomputer system (500).

The core (540) can include one or more Central Processing Units (CPU)(541), Graphics Processing Units (GPU) (542), specialized programmableprocessing units in the form of Field Programmable Gate Areas (FPGA)(543), hardware accelerators for certain tasks (544), graphics adapters(550), and so forth. These devices, along with Read-only memory (ROM)(545), Random-access memory (546), internal mass storage such asinternal non-user accessible hard drives, SSDs, and the like (547), maybe connected through a system bus (548). In some computer systems, thesystem bus (548) can be accessible in the form of one or more physicalplugs to enable extensions by additional CPUs, GPU, and the like. Theperipheral devices can be attached either directly to the core's systembus (548), or through a peripheral bus (549). In an example, the screen(510) can be connected to the graphics adapter (550). Architectures fora peripheral bus include PCI, USB, and the like.

CPUs (541), GPUs (542), FPGAs (543), and accelerators (544) can executecertain instructions that, in combination, can make up theaforementioned computer code. That computer code can be stored in ROM(545) or RAM (546). Transitional data can also be stored in RAM (546),whereas permanent data can be stored for example, in the internal massstorage (547). Fast storage and retrieve to any of the memory devicescan be enabled through the use of cache memory, that can be closelyassociated with one or more CPU (541), GPU (542), mass storage (547),ROM (545), RAM (546), and the like.

The computer readable media can have computer code thereon forperforming various computer-implemented operations. The media andcomputer code can be those specially designed and constructed for thepurposes of the present disclosure, or they can be of the kind wellknown and available to those having skill in the computer software arts.

As a non-limiting example, the computer system having architecture(500), and specifically the core (540) can provide functionality as aresult of processor(s) (including CPUs, GPUs, FPGA, accelerators, andthe like) executing software embodied in one or more tangible,computer-readable media. Such computer-readable media can be mediaassociated with user-accessible mass storage as introduced above, aswell as certain storage of the core (540) that are of non-transitorynature, such as core-internal mass storage (547) or ROM (545).

The software implementing various embodiments of the present disclosurecan be stored in such devices and executed by core (540). Acomputer-readable medium can include one or more memory devices orchips, according to particular needs. The software can cause the core(540) and specifically the processors therein (including CPU, GPU, FPGA,and the like) to execute particular processes or particular parts ofparticular processes described herein, including defining datastructures stored in RAM (546) and modifying such data structuresaccording to the processes defined by the software. In addition to or asan alternative, the computer system can provide functionality as aresult of logic hardwired or otherwise embodied in a circuit (forexample: accelerator (544)), which can operate in place of or togetherwith software to execute particular processes or particular parts ofparticular processes described herein. Reference to software canencompass logic, and vice versa, where appropriate. Reference to acomputer-readable media can encompass a circuit (such as an integratedcircuit (IC)) storing software for execution, a circuit embodying logicfor execution, or both, where appropriate. The present disclosureencompasses any suitable combination of hardware and software.

In the embodiments and implementation of this disclosure, any stepsand/or operations may be combined or arranged in any amount or order, asdesired. Two or more of the steps and/or operations may be performed inparallel. Embodiments and implementations in the disclosure may be usedseparately or combined in any order. Further, each of the methods (orembodiments), a client, and a server may be implemented by processingcircuitry (e.g., one or more processors or one or more integratedcircuits). In one example, the one or more processors execute a programthat is stored in a non-transitory computer-readable medium.

While this disclosure has described several exemplary embodiments, thereare alterations, permutations, and various substitute equivalents, whichfall within the scope of the disclosure. It will thus be appreciatedthat those skilled in the art will be able to devise numerous systemsand methods which, although not explicitly shown or described herein,embody the principles of the disclosure and are thus within the spiritand scope thereof.

What is claimed is:
 1. A method by a dynamic adaptive streaming overHTTP (DASH) media streaming device for processing an alternative mediapresentation description (MPD) with a main MPD from a content server,the method comprising: receiving a manifest for the alternative MPD fromthe content server by the DASH media streaming device; parsing themanifest to extract a set of parameters for the alternative MPD, the setof parameters comprising at least one of a value for a DASH eventstream, a presentation time, or a duration, wherein the presentationtime indicates an offset in which an alternative media presentationstarts in a timeline of a main media presentation, and the durationindicates a period in which the alternative media presentation isactive; switching from a main media presentation to an alternative mediapresentation based on the presentation time; and in response to endingthe alternative media presentation, playing back the main mediapresentation at a return point according to the value for the DASH eventstream.
 2. The method of claim 1, wherein: the presentation time is adifferent parameter from an actual switching time.
 3. The method ofclaim 1, wherein: the duration is a different parameter from an actualduration of the alternative media presentation.
 4. The method of claim1, wherein: the value for the DASH event stream comprises a first valueindicating timeshift; and the main media presentation is played back toa moment that the main media presentation is switched to the alternativemedia presentation.
 5. The method of claim 1, wherein: the value for theDASH event stream comprises a second value indicating replace; inresponse to a first MPD type indicating dynamic, the main mediapresentation is played back to a live edge of the main mediapresentation; and in response to a second MPD type indicating static,the main media presentation is played back to a moment that the mainmedia presentation is switched to the alternative media presentationplus an actual duration of the alternative media presentation.
 6. Themethod of claim 1, wherein: the alternative MPD is processed anddispatched according to a dynamic adaptive streaming over hypertexttransfer protocol (DASH) event processing.
 7. The method of claim 1,wherein ending the alternative media presentation comprises at least oneof the following: ending playing the alternative media presentation atan end of the duration; or stopping playing the alternative mediapresentation upon receiving a stop instruction.
 8. The method of claim1, wherein in response to an MPD type indicating dynamic: in response tothe value indicating replace, a return point for playing back the mainmedia presentation is a live edge of the main media presentation; and inresponse to the value indicating timeshift, the return point for playingback the main media presentation is an earliest segment available at orafter an actual switching time.
 9. The method of claim 1, wherein inresponse to an MPD type indicating static: in response to the valueindicating replace, a return point for playing back the main mediapresentation is a summation of an actual switching time and an actualduration of the alternative media presentation; and in response to thevalue indicating timeshift, the return point for playing back the mainmedia presentation is the actual switching time.
 10. A dynamic adaptivestreaming over HTTP (DASH) media streaming device for processing analternative media presentation description (MPD) with a main MPD from acontent server, the DASH media streaming device comprising a memory forstoring instructions and a processor for executing the instructions to:receive a manifest for the alternative MPD from the content server;parse the manifest to extract a set of parameters for the alternativeMPD, the set of parameters comprising at least one of a value for a DASHevent stream, a presentation time, or a duration, wherein thepresentation time indicates an offset in which an alternative mediapresentation starts in a timeline of a main media presentation, and theduration indicates a period in which the alternative media presentationis active; switch from a main media presentation to an alternative mediapresentation based on the presentation time; and in response to endingthe alternative media presentation, play back the main mediapresentation at a return point according to the value for the DASH eventstream.
 11. The DASH media streaming device of claim 10, wherein: thepresentation time is a different parameter from an actual switchingtime.
 12. The DASH media streaming device of claim 10, wherein: theduration is a different parameter from an actual duration of thealternative media presentation.
 13. The DASH media streaming device ofclaim 10, wherein: the value for the DASH event stream comprises a firstvalue indicating timeshift; and the main media presentation is playedback to a moment that the main media presentation is switched to thealternative media presentation.
 14. The DASH media streaming device ofclaim 10, wherein: the value for the DASH event stream comprises asecond value indicating replace; in response to a first MPD typeindicating dynamic, the main media presentation is played back to a liveedge of the main media presentation; and in response to a second MPDtype indicating static, the main media presentation is played back to amoment that the main media presentation is switched to the alternativemedia presentation plus an actual duration of the alternative mediapresentation.
 15. The DASH media streaming device of claim 10, wherein:the alternative MPD is processed and dispatched according to a dynamicadaptive streaming over hypertext transfer protocol (DASH) eventprocessing.
 16. The DASH media streaming device of claim 10, wherein inresponse to an MPD type indicating dynamic: in response to the valueindicating replace, a return point for playing back the main mediapresentation is a live edge of the main media presentation; and inresponse to the value indicating timeshift, the return point for playingback the main media presentation is an earliest segment available at orafter an actual switching time.
 17. The DASH media streaming device ofclaim 10, wherein in response to an MPD type indicating static: inresponse to the value indicating replace, a return point for playingback the main media presentation is a summation of an actual switchingtime and an actual duration of the alternative media presentation; andin response to the value indicating timeshift, the return point forplaying back the main media presentation is the actual switching time.18. A non-transitory computer-readable storage medium for storinginstructions, the instructions when executed by a processor of a dynamicadaptive streaming over HTTP (DASH) media streaming device forprocessing an alternative media presentation description (MPD) with amain MPD from a content server, are configured to cause the DASH mediastreaming device to: receive a manifest for the alternative MPD from thecontent server; parse the manifest to extract a set of parameters forthe alternative MPD, the set of parameters comprising at least one of avalue for a DASH event stream, a presentation time, or a duration,wherein the presentation time indicates an offset in which analternative media presentation starts in a timeline of a main mediapresentation, and the duration indicates a period in which thealternative media presentation is active; switch from a main mediapresentation to an alternative media presentation based on thepresentation time; and in response to ending the alternative mediapresentation, play back the main media presentation at a return pointaccording to the value for the DASH event stream.
 19. The non-transitorycomputer-readable storage medium of claim 18, wherein: the presentationtime is a different parameter from an actual switching time.
 20. Thenon-transitory computer-readable storage medium of claim 18, wherein:the duration is a different parameter from an actual duration of thealternative media presentation.